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RE MARKS 

The Examiner has rejected Claims 12-22 under 35 U.S.C. 101 as being directed 
toward non-statutory subject matter. Such rejection is deemed moot by virtue of the 
claim clarifications made to independent Claim 12 hereinabove. 

The Examiner has rejected Claims 1-5, 7, 9, 12-16, 18, 20, 23, 26, 29, and 33 
under 35 U.S.C. 103(a) as being unpatentable over ConSeal PC FIREWALL Technical 
Summary (hereinafter ConSeal) in view of Hari et al (Detecting and resolving packet 
fdter conflicts). Moreover, the Examiner has rejected Claim 28 under 35 U.S.C. 103(a) 
as being unpatentable over ConSeal and Hari in view of Brock et al. (U.S . Patent No. 
2003/01 10393). Applicant respectfully disagrees with such rejections, especially in view 
of the amendments made hereinabove to the independent claims. Specifically, applicant 
has amended the independent claims to at least substantially include the subject matter of 
former dependent Claim 9 et al. 

With respect to the independent claims, the Examiner has relied on the following 
excerpts from the ConSeal reference to make a prior art showing of applicant's claimed 
"...executing security actions associated with the active policies if associated limits are 
met" (see this or similar, but not necessarily identical language in the independent claims 
- emphasis added). 



"ConSeal PC FIREWAUj Technical Information 

* Runs on any Windows 95/98 or Windows NT 3.51 and 4.0 
platform with a serial or Ethernet device 

* Filters all data packets by capturing them at the device 
(link layer) level, including IP (e.g. TCP, UDP, ICMP) , NetBEUI, 
IPX, ARP, etc. 

'* Filters "all services - file and printer shares, protocols 
that use Winsock (e.g. SMTP, HTTP) and operating system services 
(e.g. ping, rip, FTP, Telnet) 

* Application and service transparency (i.e. no plug-ins or 
add-ons to enable applications or services to pass through the 
firewall) 

* Controls access to system resources, including I? address 
specific filtering 

* Manual, automatic, checked and unchecked learning modes 
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* Constant monitoring for all traffic passing in or out of 
the system . . 

* Environment sensitive rulesets-rulesets for when a specxnc 
application runs, for a specific driver, for a dialup phone 
number X, for a VPN device, etc The system manages rulesets 
activation and conflicts behind the scenes. 

* User- friendly ruleset viewing, editing and display tools 

* Optional password protection of rulesets 

* Compatibility with all other Windows 95/96 and Windows NT 
3.51 and 4.0 encryption and security software 

* Year 2000 compliant 

* Complete logging services" (ConSeal, Page 1 - emphasis 
added) 

Applicant respectfully asserts that the excerpt(s) from ConSeal as relied upon by 
the Examiner teaches that the . .system manages rulesets activation and conflicts behind 
the scenes" (emphasis added). However, the ConSeal excerpt fails to disclose a 
technique of . .executing security actions associated with the active policies if 
associated limits are met " (emphasis added), as claimed by applicant. 

In addition, the Examiner has relied on the following excerpts from the Hari 
reference to make a prior art showing of applicant's claimed technique , .wherein a fnst 
policy with a higher priority has a first condition associated therewith that is different 
from a second condition associated with a second policy with a lower priority such that 
the first policy and second policy are activated under different priority-related 
conditions" and w . . . identifying currently executed security actions, determining whether 
a conflict exists between the currently executed security actions, and resolving any 
conflicts between die currently executed security actions" (see this or similar, but not 
necessarily identical language in the independent claims). 

"a) The first matching filter in the filter database takes 
precedence. For example, if Pi is stored before F2 in the 
database, then the flow goes through at 100 Mbps. On the other 
hand, if F2 is stored before Fl, than most packets of the flow 
axe dropped, since the flow is restricted to a BW of only 1 Mbps. 
Thie approach is commonly used to resolve conflicts in firewalls, 
where incoming packets are matched against filters specified in 
access control lists and the action is determined by the first 
matching filter. 

b) Assign priorities to difference filters/ and use the matching 
filter with the highest priority. This scheme turns out to be 
identical to scheme a) if we sort the fitlers in the order of 
priority. 
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c) Assign priorities to fields so that in case of multiple 
matches tb« filter with the most specific Hatching field with the 
highest priority is selected. For example, if the source address 
is given higher priority on matches than the destination address, 
then for packets going from network X to network Y the filter fi 
is a better match than F2." (Hari, page 1204, section II - 
emphasis added) 

Applicant respectfully asserts that the excerpt from Hari relied upon by the 
Examiner teaches a method conflict resolution where one filter is selected over other 
potential filters. Specifically, for conflict resolution, the Hari excerpt referenced above 
teaches three conflict resolution techniques. The first conflict resolution technique 
disclosed teaches that "[t]he first matching filter in the filter database takes precedence" 
(emphasis added). The second conflict resolution technique disclosed teaches to 
"[a]ssign priorities to difference filters, and use the matching filter with the highe s t 
priority" (emphasis added). The third conflict resolution technique disclosed teaches to 
"[a]ssign priorities to fields so that in case of multiple matches the filter with the most 
s pecific matchinp field with ftp highest priority is selected" (emphasis added). 

Thus, excerpt from Hari referenced above actually teaches away from applicant's 
claimed technique ". . .wherein a first policy with a higher priority has a first condition 
associated therewith that is different from a second condition associated with a second 
policy with a lower priority such that the first polic y and second policy are activated 
nnHftr differe nt priority-related conditions" (emphasis added), as claimed by applicant, 
since Hari teaches that a selection of the filters is based on the same priority-related 
condition [namely, condition a), b), or c) in the above excerpt]. Note that Hari does not 
teach that a first filter is selected based on technique a) while a second filter is selected 
based on technique b), etc. 



To establish a prima facie case of obviousness, three basic criteria must be met. 
First, there must be some suggestion or motivation, either in the references themselves or 
in the knowledge generally available to one of ordinary skill in the art, to modify the 
reference or to combine reference teachings. Second, there must be a reasonable 
expectation of success. Finally, the prior art reference (or references when combined) 
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must teach or suggest all the claim limitations. The teaching or suggestion to make the 
claimed combination and the reasonable expectation of success must both be found in the 
prior art and not based on applicant's disclosure. In re Vaeck,947 F.2d 488, 20 USPQ2d 
1438(Fed.Cir.l991). 

Applicant respectfully asserts that at least the third element of the prima facie 
case of obviousness has not been met, since the prior art references, when combined, fail 
to teach or suggest all of the claim limitations, as noted above. Nevertheless, despite 
such paramount deficiencies and in the spirit of expediting the prosecution of the present 
application, applicant has amended the independent claims to further distinguish 
applicant's claim latiguage from the above reference by incorporating the subject matter 
of former Claim 9 et al, as follows: 

"wherein the conditions include a time factor, the time factor including at least 
one timeframe, time period, or time limit" (see this or similar, but not necessarily 
identical language in the independent claims). 

With tespect to the subject matter of former Claims 9 and 20 (now at least 
substantially incorporated into the independent claims), the Examiner has relied on the 
following excerpt from the ConSeal reference to make a prior art showing of applicant's 
claimed feature. 

^ConSeal PC FIREWALL allows you to construct rules that allow or 
disallow packets: 

* when a specific application is running.-" {ConSeal, Page 2 - 
emphasis added) 

Applicant respectfully asserts that the excerpt from ConSeal relied upon by the 
Examiner simply discloses "when a specific application is running" (emphasis added). 
This rejection is now moot due to the clarifications made to further clarify the time factor 
to include . . . at least one of a timeframe, a time period, and a time limit" (emphasis 
added), as claimed by applicant. 
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Applicant further notes that the prior art is also deficient with respect to the 
dependent claims. For example, with respect to Claims 2-3, and 13-14 the Examiner has 
relied on the following excerpt from Conseal from the above reference to make a prior art 
showing of applicant's claimed technique c * . . .comprising determining whether a user 
confirms the activation of the policies" (see this or similar, but not necessarily identical 
language in dependent Claims 2 and 13) and "...comprising activating the policies if the 
user confirms" (see this or similar, but not necessarily identical language in dependent 
Claims 3 and 14). 

"Conseal PC FIREWALL'S learning modes allow rules and mlesets to 
toe generated efficiently and straightforwardly. The Manual 
Learning Mode allows users to add, edit and delete their rules 
and tweak them according to address, service type and so on. The 
Checked Learning Mode prompts the user for rule generation when 
it encounters a packet for which it has no rule. The Unchecked 
Learning Mode allows users to generate rules in the background toy 
performing their normal networking activities over a trial 
period." (ConSeal, Page 2 - emphasis added) 

Applicant respectfully asserts that the excerpt from ConSeal relied upon by the 
Examiner merely teaches a technique where the "Checked Learning Mode prompts the 
user for rule generation when it encounters a packet for which it has no rule" (emphasis 
added). However, there is no disclosure of a technique . .comprising determining 
whether a user confirms the activation of the policies " (emphasis added) and . .further 
comprising activating the policies if the user confirms" (emphasis added), as claimed by 
applicant Thus, the ConSeal excerpt fails to disclose all of applicant's claimed 
technique. 

In addition, with respect to Claims 4-5 and 15-16, the Examiner has relied on the 
following excerpts from ConSeal to make a prior art showing of applicant's claimed 
technique "...comprising updating the set of policies" (see this or similar, but not 
necessarily identical language in dependent Claims 4 and 15) and "...wherein the 
updating includes receiving another inactive policy, determining whether the user accepts 
the inactive policy, and adding the inactive policy to the set if the user accepts the 
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inactive policy" (see this or similar, but not necessarily identical language in dependent 
Claims 5 and 16)> 

«* Protect access to rulesets. For example, do not allow anyone 
without the password to change rulesets. This would allow a 
system administrator to force a rule that would disallow print 
shares over a VFJJ connection. 

* Experts and novices can develop rulesets easily or allow them 
to be generated by system usage." (ConSeal, Page 2 - emphasis 
added) 

** ConSeal PC FIREWALL'S learning modes allow rules and rulesets 
to be generated efficiently and straightforwardly. The Manual 
Learning Hode allows users to add, edit and delete their 
and tweak them according to address, service type and so on. The 
Checked Learning Mode prompts the user for rule generation when 
it encounters a packet for which it has no rule. The unchecked 
Learning Mode allows users to generate rules in the background by 
performing their normal networking activities over a trial 
period." (ConSeal, Page 2 - emphasis added) 

Applicant respectfully asserts that the above excerpts from ConSeal as relied upon 
by the Examiner disclose a technique to ''[protect access to rulesets,.. [to] ...allowa 
system administrator to force a rule" and that "[e]xperts and novices can develop 
rulesets" (emphasis added). However, the ConSeal excerpts fail to even suggest a 
technique "wherein the updating includes receiving another inactive policy., determining 
whether the user accepts the inactive policy, and adding the in active policy to the set if 
the user accepts the inactive policy" (emphasis added), as claimed by applicant. There is 
simply no disclosure on "receiving another inactive policy" (emphasis added), as claimed 
by applicant. 

Further, with respect to Claims 1 0 and 21 , the Examiner has relied upon the 
following excerpts from Beebe to make a prior art showing of applicant's claimed 
technique "wherein the conditions include a soutce of the policies" (see this or similar, 
but not necessarily identical language in dependent Claims 10 and 21), 

* [0227] Referring to FIG. 12E, in step 902, corporate -dictated 
rules, similar to those described previously with reference to 
FIGS. 12C and 12D, that will comprise the basic security policy 
to be distributed downward from the ^corporate- level B06 to each 
"regional 11 level 80B Firewall Management Server 26 (such as the 



PAGE 18/21 ' RCVD AT 4/18/2006 7:43:49 PM [Eastern Daylight Time] * SVR:USPT0-EFXRF-2/1 1 * DNIS:2738300 * CSID:4089714660 * DURATION (mm-ss):0542 



APR. 1 8. 2006 4:58PM Z I L KA-KOTAB, PC 

-16- 



NO. 2646 P. 19 



one in San Francisco 814), and to each "branch" level 910 
Firewall Management Server 25 (such as those in salt Lake City 
820 and Denver 822), are defined, in step 904 the corporate- 
Rotated rules are merged into the current security Rule Base 102 
of the security Policy 100. As mentioned previously, tne 
corporate dictated rules will have priority over and remove any 
coSuc^f rules, in step 906, the updated Security ^licy 100 
is downloaded to the local Line Sensors 18 on the -corporate 
level 80€.' (Beebe, paragraph 0227 - emphasis added) 

Applicant respectfully asserts that the excerpt from Beebe relied upon by the 
Examiner teaches that 'the basic security policy to be distribute downward from the 
"corporate" level ... to each "regional" level ... and to each "branch" level' (emphasis 
added). During the downward distribution, the "corporate-dictated rules will have 
parity over and i^^ ™v conflicting rules" (emphasis added). The excerpt from 
Beebe thus merely teaches roles for "basic security policy" distribution and fails to make 
any disclosure where "■■ . conditions include a source of the policies" (emphasis added), as 
claimed by applicant. 

In addition, with respect to Claims 1 1 and 22, the Examiner has relied upon the 
following excerpt from Porras to make a prior art showing of applicant's claimed 
technique "wherein the conditions include a severity of security actions associated with 
the policies" (see Ibis ot similar, but not necessarily identical language in dependent 
Claims 11 and 22), 

"In a further aspect, alerts may be tagged with a priority 
indication flag formulated against the remote processing 
station's alert processing policy and tagged with a relevance 
flag that indicates tie likely severity of the attack wxtli 
respect to the known internal topology of the monitored network." 
(Porras, col. 2, lines 46-51 - emphasis added) 

Applicant respectfully asserts that the above excerpt from Porras merely teaches a 
technique where "alerts may be tagged wilh a priority indication flag . , , and tagged with 
a relevance flag that indicates the likely severity of the attack" (emphasis added). 
Tagging alerts in no way even suggests a technique "wherein the conditions include a 
rit yftf security actions associated with the policies" (emphasis added), as claimed by 



sevent 



applicant. 
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Also, with respect to Claim 28, the Examiner has relied upon the following 
excerpt from Brock to make a prior art showing of applicant's claimed technique 
"wherein the conditions represent an urgency associated with an issue causing the policy 
to be activated" (emphasis added). 



* [0005] When the intrusion detection system observes activity 
that is suggestive or indicative of an intrusion, for example 
when the value of a signature event counter crosses its 
associated signature threshold, the IDS may generate an alert. 
The purpose of the alert is to inform a networfc administrator of 
the intrusion, so that the administrator may act to minimize the 
damage done by the intruder. The alert m&y include other 
information drawn from the particular signature that is 
associated with the suspected intrusion, such as a priority or 
importance level suggesting the urgency of the need for defensive 
action, or instructions or data to help the administrator limit 
the damage done by the intruder." (Brock, Paragraph 005 - 
emphasis added) 

Applicant respectfully asserts that the excerpt relied upon by the Examiner 
teaches that the "alert is to inform a network administrator of the intrusion, so that the 
administrator may act to minimize the damage done by the intruder" (emphasis added). 
Further, the "alert may include ... a priority or importance level suggesting the urgency 
of the need for defensive action " However;, an administrator action to an alert fails to 
disclose a technique "therein the conditions represent an urgency associated with an 
issue causing the policy to be activated" (emphasis added), as claimed by applicant. 



Again, applicant respectfully asserts that at least the third element of the prima 
facie case of obviousness has not been met, since the prior art references, when 
combined, fail to teach or suggest all of the claim limitations, as noted above. Thus, a 
notice of allowance or specific prior art showing of each of the foregoing claim elements, 
in combination with the remaining claimed features, is respectfully requested. 



Therefore, all of the independent claims are deemed allowable. Moreover, the 
remaining dependent claims are further deemed allowable, in view of their dependence 
on such independent claims. 
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In the event a telephone conversation would expedite the prosecution of this 
application, the Examiner may reach the undersigned at (408) 505-5 1 00. The 
Commissioner is authorized to charge any additional fees or credit any overpayment to 
Deposit Account No. 50-1351 (Order No. NAI1P048). 



P.O. Box 721 120 

San Jose, CA 95 172-1 120 

408-505-5100 
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